A storage system typically comprises one or more storage devices into which information may be entered, and from which information may be obtained, as desired. The storage system includes a storage operating system that functionally organizes the system by, inter alia, invoking storage operations in support of a storage service implemented by the system. The storage system may be implemented in accordance with a variety of storage architectures including, but not limited to, a network-attached storage environment, a storage area network and a disk assembly directly attached to a client or host computer. The storage devices are typically disk drives organized as a disk array, wherein the term “disk” commonly describes a self-contained rotating magnetic media storage device. The term disk in this context is synonymous with hard disk drive (HDD) or direct access storage device (DASD).
The storage operating system of the storage system may implement a high-level module, such as a file system, to logically organize the information stored on volumes as a hierarchical structure of data containers, such as files and logical units. For example, each “on-disk” file may be implemented as set of data structures, i.e., disk blocks, configured to store information, such as the actual data for the file. These data blocks are organized within a volume block number (vbn) space that is maintained by the file system. The file system may also assign each data block in the file a corresponding “file offset” or file block number (fbn). The file system typically assigns sequences of fbns on a per-file basis, whereas vbns are assigned over a larger volume address space. The file system organizes the data blocks within the vbn space as a “logical volume”; each logical volume may be, although is not necessarily, associated with its own file system.
A known type of file system is a write-anywhere file system that does not overwrite data on disks. If a data block is retrieved (read) from disk into a memory of the storage system and “dirtied” (i.e., updated or modified) with new data, the data block is thereafter stored (written) to a new location on disk to optimize write performance. A write-anywhere file system may initially assume an optimal layout such that the data is substantially contiguously arranged on disks. The optimal disk layout results in efficient access operations, particularly for sequential read operations, directed to the disks. An example of a write-anywhere file system that is configured to operate on a storage system is the Write Anywhere File Layout (WAFL®) file system available from Network Appliance, Inc., Sunnyvale, Calif.
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access data containers stored on the system. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network (LAN), wide area network (WAN), or virtual private network (VPN) implemented over a public network such as the Internet. Each client may request the services of the storage system by issuing file-based and block-based protocol messages (in the form of packets) to the system over the network.
A plurality of storage systems may be interconnected to provide a storage system environment configured to service many clients. Each storage system may be configured to service one or more volumes, wherein each volume stores one or more data containers. Yet often a large number of data access requests issued by the clients may be directed to a small number of data containers serviced by a particular storage system of the environment. A solution to such a problem is to distribute the volumes serviced by the particular storage system among all of the storage systems of the environment. This, in turn, distributes the data access requests, along with the processing resources needed to service such requests, among all of the storage systems, thereby reducing the individual processing load on each storage system. However, a noted disadvantage arises when only a single data container, such as a file, is heavily accessed by clients of the storage system environment. As a result, the storage system attempting to service the requests directed to that data container may exceed its processing resources and become overburdened, with a concomitant degradation of speed and performance.
One technique for overcoming the disadvantages of having a single data container that is heavily utilized is to stripe the data container across a plurality of volumes configured as a striped volume set (SVS), where each volume is serviced by a different storage system, thereby distributing the load for the single data container among a plurality of storage systems. In a striped file system utilizing a SVS, a conventional technique for striping data across the constituent volumes is to utilize dense data containers, i.e., data is stored from offset zero through the end of the data container with no regions of the data container that lack storage. In such a dense data container, the first stripe of data in a first volume of the SVS is stored at offset zero within the data container. Assuming that the data container is sufficiently large so as to “wrap around” all of the volumes in the SVS, the next stripe of data that is stored on the same first volume is stored at an offset equal to the size of each stripe.
For example, assume a SVS contains data striped across three volumes with the stripe size equal to 1 MB. A 5 MB dense data container, such as a file, is stored on the SVS with a first stripe at offset zero of a first volume, a second stripe at offset zero of a second volume and a third stripe at offset zero of a third volume. Similarly, a fourth stripe is stored at offset 1 MB on the first volume and a final stripe is stored at offset 1 MB of the second volume. In order to efficiently access a particular stripe of data, the file system must be able to quickly calculate the appropriate offset based upon striping rules and stripe size. While this offset calculation typically may be made in constant time, the constant time may be significant if a complex striping algorithm is utilized, thereby increasing the latency in serving data. Furthermore, in such a dense file, there exists a possibility that the metadata identifying the striping algorithm and/or stripe size may be damaged and/or corrupted. In such a situation, determining the order of stripes of data within the SVS may be impossible, thereby resulting in data loss.
Additionally, should the data within the SVS need to be re-striped due to, for example, the addition of a volume to the SVS, the calculations required to safely re-stripe a densely stored file may be substantial. Such a re-striping operation may require relocation of significant portions of the data, which may consume a considerable amount of time. Re-striping may also require multiple copy operations to relocate each stripe to the proper location, which increases the time required to perform the re-striping operation.